Azure Blockchain Workbenchアーキテクチャ概要
Azureは仮想マシンクラスタ構成テンプレート機能も提供していて、Blockchain Workbenchを使わずにブロックチェーンネットワークを構成することもできる。
対応プロトコル (2018.8.22現在)
Ethereum
Hyperledger Fabric (将来対応予定)
Corda (将来対応予定)
アーキテクチャ
クラウドテンプレート的な機能によって下記環境がセットアップされる。
https://docs.microsoft.com/ja-jp/azure/blockchain-workbench/media/blockchain-workbench-architecture/architecture.png
Azure Active Directory (Azure AD) によるIDフェデレーション
認証機能を提供
クライアントアプリケーション
Web, iOS, Android
スマートコントラクトのメタデータに基づいて動的に生成される
デプロイのたびに自動ビルドされる？
Azure ADでユーザ認証
ゲートウェイサービスAPI
ブロックチェーン書き込み→このAPIがメッセージ生成 (誰がAPI叩く？) →イベントブローカー (Service Bus) に配信
このAPIにデータ要求→オフチェーンSQLデータベースにクエリ発行してデータ取得
Azure ADで認証
受信メッセージ用のメッセージブローカー
Azure Service Busによって提供される
APIを介さず、ここに直接メッセージ送信してもいい
システム間の統合やIoTデバイスに使用できる
ダウンストリーム用のメッセージブローカー
2種類のイベントコンシューマーが生成される (図のどれなのかよく分からない。描かれてないかも)
ブロックチェーンイベントによってトリガーされ、オフチェーンSQLデータストアに投入するコンシューマー
ドキュメントのアップロードと保存に関連したAPIによって生成されるイベントのメタデータを取得するコンシューマー
メッセージコンシューマー
Service Busからメッセージを取得する
3種類のメッセージコンシューマーが自動生成される
DLT (Distributed Ledger Technology) コンシューマー
受信したメッセージに含まれるトランザクションのメタデータをトランザクションビルダーにプッシュ
データベースコンシューマー
ストレージコンシューマー
受信したメッセージのデータをストレージにプッシュ
トランザクションビルダー
DLTコンシューマーから受け取ったデータを適切なトランザクションにビルドして署名する
Ethereum, Hyperledger Fabric, Cordaなど宛先に応じてトランザクションの形式が変わる
秘密鍵はAzure Key Vaultに保存される
署名が完了するとルーターに送信する
トランザクションルーター
トランザクションを受け取り、適切なブロックチェーンに送信する
現在 (2018.8.22) のターゲットはEthereumのみサポート
DLT Watcher
管理しているブロックチェーンで発生したイベントを監視
新たなコンストラクトアカウントの作成、トランザクションの実行、状態の変更など
Azure SQLデータベース
コントラクト定義、設定メタデータ、ブロックチェーンに格納されたデータのレプリカ
Azureストレージ
メタデータ格納 (画像など)
メタデータのハッシュ値をブロックチェーンに格納
モニタリング
Application Insights, Azure Monitor
アプリケーションロギング
所感（ファーストインプレッション）
システムを構築する際、ブロックチェーン台帳だけでシステムが完結するということはない。参照・更新用のクライアントアプリケーション、モバイル対応、フロントエンドサーバーのスケーリング、大量参照、大量更新に耐えられるブロックチェーン台帳のレプリカDBやキャッシュ、メタデータストレージ、サービスモニタリングなど、用意しなければならないコンポーネント、対応しなければならない作業は多岐にわたる。
Azure Blockchain Workbenchを利用することで最低限必要なコンポーネントが一気に揃うというのは、素早い初動を得られて非常に良さそう。
また、伝統的なWEBの三層アーキテクチャや非同期なコンポーネントを採用するもう少し複雑なシステムと比べても、ブロックチェーンを利用したシステムのアーキテクチャは複雑になりがち。Azure Blockchain Workbenchのようなリファレンスアーキテクチャ、あるいはベストプラクティスを構築するようなサービスは複雑なシステムの見通しをよくしてくれるので、要件にフィットするのであればどんどん採用していきたい。
まだ実際に開発・運用で利用したわけではないので、使った後また記事にしたい。
参考情報
勉強会中のコメントメモ@8/30
nrryuya.icon < このアーキテクチャのバックエンドを、コンソーシアム参加組織が各自でバラバラに作るのだろうか？
nrryuya.icon < 結局プライベートチェーンBaaS界隈で最強なのは誰なの？
nrryuya.icon < 各バックエンドごとに一つで、一応参加組織ごとに鍵を作るんじゃなかろうか、HyperledgerのCA証明書みたいなやつのように。
でもその場合Azure SQLの整合性どうするんだろう
shuntak.icon ブロックチェーン上のデータのレプリカなら整合性が取れると思いますが、各組織で作った独自テーブル（解析用の中間テーブルなど）は独自に同期しないといけないと思います
moonty_sal.icon 各エンドユーザの「アカウント」みたいのってPrivate なPoAだとあるんだっけ？ないんだっけ？
アカウントあるなら秘密鍵がユーザごとに割り当てられてる気がするのでKey Valutにはいってるのかな？
shuntak.icon < クライアントアプリのエンドユーザーという観点だと、ブロックチェーンとクライアントアプリが利用するゲートウェイAPIの認証は完全に別です
moonty_sal.icon azs そもそもPoAは優しい世界なのをちゃんと認識してなかった
yamarkz.icon < 秘密鍵は1つ
Azure Key Vaultで署名する
shuntak.icon < Workbenchで作成した構成だと、ブロックチェーンのクライアント証明書（秘密鍵）は一つの組織につき一つと思われる